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Method and Device Utilizing Polymorphic Data in E-Commerce 

Inventor: MuditaJain 
Jari Koistinen 
Charles Boyle 
Brian Hayes 

Copyright Notice 

A portion of the disclosure of this patent document contains material which is 
subject to copyright protection. The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent document or the patent disclosure as it appears in 
the Patent and Trademark Office patent file or records, but otherwise reserves all 
copyright rights whatsoever. 

Background of the Invention 

Field of the Invention 

The present invention relates to use of polymorphic data in a session between a buyer 
and seller, or any pair of trading partners, mediated by a broker or e-commerce hub. In 
particular, methods and devices utilizing a flexible service request and session end messages 
are described. 

Description of Related Art 

A desire for electronic commerce brings trading partners together. Broker or hub 
applications can facilitate transactions between trading partners in many ways. The broker 
application can field an initial session start request from the buyer and forward it to a seller, 
either acknowledging the start of the session explicitly or leaving it to the seller to 
acknowledge the start of the session to the buyer. This and other variations on the manner in 
which electronic commerce is implemented have implications for software design. 

Summary of Invention 

An aspect of the present invention includes a protocol for conveying data during an e- 
commerce session with a polymorphic response, comprising initiating a session with a first 
message from a buyer application to a broker application and a second message from the 
broker application to a supplier application; conducting the session between the buyer 
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application and the supplier application; and responding during the session with an additional 
message which includes a schema identifier for the additional message, resolvable in a 
context of a system identifier and a polymorphic response comprising a type and a version, 
wherein the polymorphic response includes additional data elements corresponding to values 
5 assigned to the type and version. Additional aspects of the invention can be found in the 
detailed description, the figures and the claims. 

Brief Description of Figures 

Figure 1 is a schematic diagram of components useful between buyer and supplier. 
10 Figure 2 is a schematic diagram of processes from subscription through purchase 

order. 

Figures 3-6 are schematic diagrams extracted from or resembling figure 3, with 
reduced detail to aid in understanding various processes. 

Figure 7 is an interaction diagram from beginning with a user's initiation of a session. 

15 

Detailed Description 

The following description of various aspects and embodiments of the invention is 
presented for purposes of illustration and description. The description is not intended to limit 
the invention to the precise forms disclosed. Many modifications and equivalent 

20 arrangements will be apparent to people skilled in the art. 

One embodiment practicing aspects of the present invention is so-called 
RoundTrip(TM) software. RoundTrip facilitates connections between buyers and suppliers 
for connecting via a MarketSite(TM) portal. Other embodiments of the present invention will 
be adapted to facilitating connections between trading partners using other e-commerce 

25 portals and connections, including OBI compliant protocols . RoundTrip software may be 
delivered as a patch to the XML commerce connector (XCC) software or as a stand alone 
package. Buyers use the XCC software or equivalent components of a stand alone package to 
process polymorphic messages involving the RoundTrip software. Suppliers optionally may 
use the XCC software. Custom adaptations to the RoundTrip software by suppliers are 

30 supported. The RoundTrip software facilitates return of shopping cart data from a supplier 
application to a buyer application, after the buyer has created the shopping cart at the supplier 
site. The buyer application can then use the shopping cart data to create a purchase order 
which it can send to the supplier application without involvement of the RoundTrip software. 
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One aspect of the present invention, found in the RoundTrip software, is use of a 
polymorphic message in the context of an e~commerce session to respond with results during 
a session, sometimes at or near the end of the session. A polymorphic message, described 
further below, is capable by design of returning shopping cart data, product configuration 
data, tax calculation data, foreign freight forwarding data, status inquiry responses or another 
form of data which reflects the interaction between the buyer and supplier. Another aspect of 
the present invention is use of a polymorphic message to initiate a session, the polymorphic 
message being adaptable to sending out purchase orders, purchase order responses, invoices, 
advance shipping notices or the like. 

In presenting the RoundTrip software embodiment, reference is made to buyers and 
suppliers. Buyers and suppliers might alternatively be referred to as trading partners. 
Reference to buyers or buyer applications is to be taken in its broadest sense as referring to a 
party or application which seeks goods, services, commercial data or the like. Reference to 
suppliers or supplier applications has a similarly broad meaning, referring to the source of 
goods, services or data which the buyer seeks out. The RoundTrip software itself is referred 
to as the broker application. This software and equivalent applications may sometimes be 
called e-conimerce hubs. 

Figure 1 illustrates software components which interact with the RoundTrip 
software. A firewall 101 surrounds these components. The RoundTrip software may be 
installed as a patch to the XCC software, both represented by 1 12. Other software 
components include an LI router 1 13, an L2 registration 1 14, and an L2 integrated supplier 
1 16 with a forwarding service 1 17. In practicing the present invention, these components of 
Commerce One's implementation of the present invention are generally interchangeable with 
components of alternative e-commerce systems. Fewer more components can be adapted to 
practicing aspects of the present invention. Software components may be deployed on one or 
more of servers in communication with each other via a secure (encrypted or physically 
secure) or insecure connection. The LI router 1 13 routes messages through the portal. It is 
useful for this router to be maintained in a DMZ, allowing it to act as a receiving point for ail 
external documents and to make HTTP/S connections with suppliers. To route messages, the 
LI router maintains a database of destinations to which it posts messages. These destinations 
can be URL addresses. The L2 registration component 114 handles and maintains 
registration of buyers. The L2 integrated supplier 1 16 provides the service of forwarding 
message to trading partners. In this case, it forwards the shopping cart received by the broker 
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application, of which it could be considered a part, to the buyer application. The XCC 
software operates at the MarketSite Messaging Layer (MML). Buyer application messages to 
the RoundTrip software are compliant with published MML layer protocols. The RoundTrip 
software can run on the NT operating system platform. It is designed to use MS SQL Server, 
5 Apache web server and JRun. Other embodiments the present invention may be adapted to 
other operating systems, databases, servers and software interpreters or compilers. The 
RoundTrip software may be positioned on the opposite side of a firewall from the buyer 
application, or on the same side. 

Figure 2 is the high-level data flow for the RoundTrip software. Figure 3-6 are 

10 excerpts or variations of this figure which illustrate various aspects of data flow. A 

RoundTrip user navigates through a sequence of links to arrive at the desired supplier's first 
page. One navigation flow is from a buyer view, to a RoundTrip home page, to a service or 
supplier selection page, to a supplier first page. An alternative navigation flow would begin 
from within a catalog, proceeding from a level corresponding to the supplier, product or 

1 5 commodity of interest. The buyer would be routed from the catalog maintained for the buyer 
to a supplier site. The session during which the buyer is in contact with the supplier may be 
referred to as a supplier service session or simply a session. The start and end of the session 
are handled by the RoundTrip software. The interaction between the buyer and supplier may 
occur directly between the user's web browser and the trading partner's web based service, or 

20 may be relayed through the broker. 

The following interaction overview can be understood with reference to figure 2. 
The supplier 240 registers with the RoundTrip software 210. This registration to be handled 
manually, through a registration agent, or online. Online registration many the subject to 
manual or off-line verification. On the buyer side, the buyer 230 subscribes to one or more 

25 RoundTrip 210 enabled services. This can be either a manual procedure or an automated 
selection. An automated selection is facilitated by use of compatible software by buyer and 
supplier. Subscription services need to be accompanied by customizations or translators 
when the supplier side software is not natively compatible with the buyer side software. A 
broker session starts when a user of the buyer application 230 initiates a session. This may 

30 include selecting the RoundTrip home page 210. Interaction during a broker session allows 
the buyer to view available services and select a specific service. In alternative embodiments, 
such as for tax calculation, a "buyer" application could automatically invoke the desired 
service through the broker application, without any explicit act of user selection. When the 
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buyer 230 selects the service, a supplier service session start document flows from the broker 
application 210 to the supplier application 240. This document may contain both data 
provided by the buyer during the session and data preregistered by the buyer in a registration 
database. This document can be transmitted by an HTTP/S Post, to a supplier provided URL 

5 with an XML format document in a hidden field. The supplier provided URL corresponds to 
location with a supplier has a script running that takes the session start document and stores it 
a database. The supplier application then does an HTTP redirect to an additional supplier 
URL that is to be seen by the buyer application. Alternatively, the broker application can 
provide the redirect data to the buyer application, for the buyer application to execute the 

10 redirect. The location at which the session start document is stored is forwarded as a 
parameter with the redirect message. This may result in a top-level page of the supplier 
service being displayed on the buyers browser. In one embodiment of the present invention, 
the supplier application at the initial URL discards any cookies received before executing the 
redirect with reference to the location where the session start document is stored, to the 

1 5 additional supplier URL. Use of an HTTP redirect is useful to facilitate proper resolution of 
relative links to the supplier URL by the buyer's browser and to facilitate proper handling of 
cookies issued by the supplier URL to a buyer browser. The buyer and supplier may proceed 
to interact directly 250. Alternatively, their interactions can be routed throught the broker. 
Upon completion of the session, the buyer ends the interaction with the supplier application, 

20 for instance by clicking an accept or cancel button. In one embodiment, this results in a 

shopping cart commitment or in a cancellation. The supplier application 240 sends a supplier 
service session end document to the the broker 210. When the interaction produces a 
shopping cart, the shopping cart data or are reference thereto is included in the message. The 
broker application 210 next transmits the session details (e.g., shopping cart) to the buyer 

25 application 230. In one embodiment, the broker application does an HTTP post of the 

message to an appropriate buyer application URL, e.g., for a procurement application. In this 
embodiment, the RoundTrip software waits for an HTTP Reply from the buyer application. 
The buyer application 230 may use the order information to create or update a requisition or 
purchase order 231 . Without need for interaction through the broker application, the buyer 

30 application may transmit this purchase order through MarketSite software 220 or directly to a 
supplier 240. Special messages can be used in cases of session cancellation, errors during the 
session between buyer and supplier, or a recoverable timeout. In the general data flow of 
figure 2, implicit login may be supported, whereby the broker stores the password for the 
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buyer's organization to be sent to the supplier and uses it upon authentication of the buyer. 
The buyer application may be configured to send a broker both the buyer's userids and 
passwords for gaining access to the RoundTrip software and to the supplier site. 
Alternatively the broker application can maintain a table of userids and passwords for 
suppliers corresponding to userids and password's provided by the buyer application. At the 
IP session level, it is useful for communications among the buyer, broker and supplier 
applications to use a secure socket layer (SSL) protocol so that the data is securely 
exchanged. 

Figure 3 focuses on registration of the supplier 240, buyer 230 and their 
applications. In one embodiment, both the buyer and supplier receive valid market 
participant IDs (MPIDs) from a MarketSite administrator. In overview, the supplier registers 
the set of services it will provide, compatible with the RoundTrip software. For each service 
the supplier provides a URL that points to the service, a URN, and the type of the service. 
The details of the supplier's service registration are described below. The buyer subscribes to 
one or more services that are RoundTrip enabled. The buyer provides URLs for receiving 
session and messages can the error messages. When the buyer is using XCC, this URL may 
be the same as the XCC URL. The buyer provides their supplier assigned account number 
and their organization MPED. The MPID may identify the buyer with any level particularly, 
such as company, department or individual buyer. Localization information also may be 
provided, such as the language, country and currency for transactions. Upon registration, the 
buyer receives a URL to which buyer application can send a broker session start request. The 
details of the buyer's service subscription are described below. Note that a contractual 
relationship between the buyer and supplier may be the basis for receiving a supplier assigned 
account number and corresponding password. A trading partner may fulfill both the rules of 
buyer and supplier in different sessions. 

The table below provides further information regarding supplier service registration, 
according to the RoundTrip software embodiment. The information set forth in the table 
enables buyer side applications to connect to and interact with a supplier's RoundTrip enabled 
services. The information described in the table may be provided either via a paper 
registration form or an online registration form verified a MarketSite operator. 
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Item 


Description 


DocumentExchange 
Protocollnformation 


Specifies the document exchange protocol and version expected 
by the supplier application, e.g., "RoundTrip" version 1.0. 


DocumentExchange 
Formatlnformation 


Specifies data format expected by the supplier application in the 
"Supplier Service Session Start" and "Supplier Service Session 
End" data messages, e.g., CBL version 2.0. 


DocumentExchange 
Timeout 


Specifies the service timeout value in minutes. 


DocumentExchange 
Securitylnformation 


Will indicate the authentication scheme imnosed bv the trading 
partner's service. Options would be implicit or explicit sign-on. 


ServiceURN 


Used as a key to lookup farther RoundTrip registry information. 
This is a supplier service specific URN, e.g., "catalog:supplier- 
name". Assigned by the MarketSite operator in agreement with 
the supplier/trading partner. 


Service! TOT 


lllv optvlHu lUUdllUil yKJD^LjJ Ui C11C 2>CIVlvC. i IUVH1CU. Uy 

supplier/trading partner. Examples: 

htttv//www <sunnlier com/catalnfy fl<*r> or 
http://www.supplier.com/cgi-bin/catalog.cgi/roundtrip or 
httn.7/www suoolier com/c^i- 
bin/catalog cri?FLAVOR=ROUNDTRIP 


S erviceS ess ionTime 
out 


Soecifies serviced user session timeout value in minutes 


TradingPartnerld 


Identifies the trading partner that is registering the service. This 
would typically be the MPId (Marketplace Id) of the supplier. 


Serviceld 


The service id unique to a supplier. 


ServiceType 


Specifies the type of service that is being run. 


ServiceName 


Service name. 


AppFieldMap 


Reserved for future use. 


AppServiceData 


Reserved for future use. 



The next table below provides further information regarding initial buyer registration, 
according to the RoundTrip software embodiment. The information described in the table 
may be provided either via a paper registration form or an online registration form verified a 
5 MarketSite operator. Default values, subject to overrides, can be assigned to many of these 
items, including localization values, the Document Exchange Protocol Information, the 
Accept and Cancel URLs and Labels 



Variable 


Description 


OrgID 


Buyer organization or BuySite identifier 


BuyerAppName 


Buyer application name/id. 


BuyerAppVersion 


Buyer application version. 


BuyerAppFrameSize 


Buyer application's frame size 


DocumentExchangeProtoc 
ol Information 


Specifies the document exchange protocol and version used. 
For the initial release, the protocol is "RoundTrip" and the 
version is 1 .0. 
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Variable 


Description 


SessionTimeOut 


Client session timeout value in minutes. 


Language 


The user preferred two-letter ISO language code. Reference 
CBL element LangCode. 


Currency 


Reference CBL element CurrencyCode. 


Country 


Can be used to determine/guess the number and date 
formats. Reference CBL element CountryCode. 


AcceptURL 


A URL to a buyer side ASP/servlef/CGI for uploading the 
configured order. 


AcceptLabel 


This is the button label that the trading partner web-based 
services will associate with the Callback URL. Optional. 


CancelURL 


A URL to a buyer side ASP/servlet/CGI for handling the 
user canceling the configurator process. 


CancelLabel 


This is the button label that the suppliers will associate with 
the Cancel URL. 



After initial registration, the buyer will specify the supplier and supplier services that it wants 
to subscribe/unsubscribe to. The following information can be used to identify supplier 
5 services to which the buyer is subscribing.: 



Variable 


Description 


OrgID 


Buyer organization or BuySite identifier 


Supplier!) 


Identifies the supplier that provides the service being 
registered to. This would typically be the MPId (Marketplace 
Id) of the supplier. 


SupplierServicelD 


The service id unique to this supplier. 



For each service, the buyer will also register and service specific data. Some examples of 
these data items are: 

10 



SupplierAssignedAccountN 
um 


For the supplier-based services, this is the customer 
number assigned by the supplier to the buying 
organization. This facilitates contract pricing. 


DistributerAssignedAccount 
Num 


For distributor-based services, this is the customer number 
assigned by the distributor to the buying organization. 
This also facilitates contract pricing. 



Figure 7 and 4 generally illustrate the processes leading to issuance of the broker session 
start document. In figure 7, interactions take place among the user 701, the user's web 
browser 702, a buyer application or BuySite 703, a broker application 704 and the supplier 
15 application 705. The user navigates to a requisitioning screen with reference to RoundTrip 
software and performs some action 710. The user's action at the requisitioning screen causes 
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an HTTP Post message 71 1 to be sent to the broker application for a broker session start. A 
schema for such a message is set forth below. The broker application verifies the user 
privileges 712 and takes other steps described in more detail below. The broker application 
issues an HTTP reply 713 to the user's web browser 702. 
5 Figure 4 provides additional detail regarding the broker application's processes in 

response to the buyer's BrokerSessionStart document. The buyer 230 sends a 
BrokerSessionStart document to the broker 210. An HTTP/S Get or Post connection can be 
used. The buyer's document contains the buyer MPDD and the buying organization's user ID 
and password. The broker 210 validates the buyer by publishing a ping document to LI 413, 

10 using the buyer MPID and buying organization's user ID and password. The LI component 
forwards the ping document to L2 414 and its ping service 415. The response is a pong 
message which validates the buyer. In an alternative embodiment, the SiteMinder™ product 
by Netegrity™ can be used to validate the buyer. Information regarding this product is 
available through http://mvw.netegritv.coni/products/siteminder.htmL Once the buyer is 

15 validated, the broker returns the list of services to which the buyer has subscribed. When the 
buyer selects one of the returned services, another HTTP/S Get or Post request from the 
browser, to the procurement application, through the broker is generated. In this 
embodiment, the buyer sends the broker a document containing the Supplier-assigned userid 
and password, and SessionID and SessionContext for the buyer session start.. The broker 

20 receives this request at the start document URL. The broker then constructs a Supplier 
Service Session Start XML document, and sends it on as an HTTP/S Post to the supplier. 

A Sox schema for RoundTrip BrokerSessionStart message appears below. Those 
familiar with the art will recognize Sox as an extension to XML proposed as an open 
specification through W3C at HTTP://www. w3.org/TR/NOTE-SOX. The full Sox 

25 specification, version 2, has been published at 

http://ww.commerceone.conVxm^ The schema below is self 

documenting. Some comments and explanations of data usage follow the schema. 

<?xml version= M 1.0"?> 
30 <!DOCTYPE schema SYSTEM 

"urn:xcommerceone:document:com:commerceone:xdk:xml:schema.d 
<schema uri= M urn:x-commerceone:docurnent:com:commerceone: 
roundtrip:schemas:RoundTripBrokerSessionStart.sox$1.0 ,, > 
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<namespace prefix- 'cbl" namespace =,, urn:x- 
commerceoneidocumentcomxommerceoneiCBLrCBL.soxSI.O 1 ^ 

<comment> 
5 Copyright 1999 Commerce One Inc. 

</comment> 

<elementtype name= ,, BrokerSessionStart"> 
<model> 
io <sequence> 

<element type- 'Login I nfo7> 
<element type- 'Sessionlnfo7> 
<element type='*PassThruData" occurs= M ?7> 
</sequence> 
is </model> 
</elementtype> 

<elementtype name="Sessionlnfo"> 
<model> 

20 <element type= ,f SessionContexr occurs="?7> 

</model> 

<attdef name-'SessionlD" datatype= M string M ><required/> 
<explain> 

<p>This is the user session id assigned by the buyer-side 
25 application. </p> 

</explain> 
</attdef> 
</elementtype> 

30 <elementtype name =,, SessionContext"> 

<model> 

<element type="string" name= fl Orgld u occurs="?7> // e.g. the BuySite 
internal Buying Organization id. 

<element type= H string M name= tt ParentOrgld" occurs="?7> <!- e.g. 
35 the BuySite internal Enterprise (EBO) Id. --> 

<element type= M string" name="Orderld" occurs="?7> <!- Id of user's 
current requisition. -> 

</model> 
</elementtype> 

40 

<elementtype name= M Loginlnfo"> 
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<explain> 

<p>The <code>Loginlnfo</code> contains the 
authentication data for signing onto the RoundTrip 
services.</p> 

<p>lt is intended that this element be extended to 
support other authentication schemes such as single 
sign-on. </p> 
</explain> 
<model> 
<sequence> 
<element type="Organization7> 
</sequence> 
</model> 
</elementtype> 

<elementtype name="Organization M > 

<attdef datatype= ,, string M name="ID"><required/> 
<explain> 

<p>The <code>Organization</code> may be identified by a 
<code>ID</code> that is known to some 
<code>Agency</code>. The <code>Agency</code> should be 
identified with an <code> Agency I D</code> (or an 
<code>AgencyOther</code>).</p> 
</explain> 
</attdef> 

<attdef name= H AgencylD" prefix= ,, cbl M 
datatype= tt AgencyCode"><required/> 
<!-- <explain> 

<p>An <code>Agency</code> chosen from a list of standard 
<code>Agencies</code>. This identifies the 
<code>Agency</code> that issued the <code>PartylD</code>. 
For MarketSites, use Other unless the specific MarketSite 
has an AgencyCode.</p> 
</explain> ~> 
</attdef> 

<attdef datatype^string" name= M AgencyOther"> 
<explain> 

<p>lf the <code>AgencylD</code> is <code>Other</code> 
the <code>Agency</code> identifier may be specified 
as a string. If the Agency is a MarketSite, use the 
MarketSite short name or MarketSite Participant ID.</p> 
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</explain> 
</attdef> 
</elementtype> 

5 <elementtype name="Pas$ThruData"> 

<explain> 

<p>A place holder element for any other data that is 
required by the application to process the document(s) and 
other information returned in the BrokerSessionEnd.</p> 
10 <p><code>Content</code> - Format to be defined by the 

application. Note it cannot be in XML format (XML data can 
be URL encoded or otherwise encoded).</p> 
</explain> 
<model> 

15 <element name- 'Content" type-'string" occurs="?7> 

</model> 
</elementtype> 
</schema> 

20 This schema works in conjunction with XML Common Business Language (xCBL) 

documents published as an open standard at the Commerce One download site referenced 
above. In other embodiments of the present invention, EBXML documents (Sun sponsored) 
or other schemas could be used for starting the broker session. The table below explains 
some data usage corresponding to the schema above. 

25 



Variable 


Description 


SessionDD 


Identifies the user session. 


SessionContext 


Session context. For example, this may include 
the user's requisition id and buyer organization Id. 


UserlD 


The user id and password field will be activated 
when single sign-on is enabled. 


Password 




OrgID 


This will be the organization's Markets ite 
Participant ID (MPID) when the OrglDAgency is 
set to a MarketSite. Alternatively, this could an 
identifier assigned by another agency such as 
EAN. ~ - - 


OrglDAgency 


This will be the identifier for the agency that 
assigned the OrgED. For example, MarketSite.net 
or EAN. 


PassThruData 


A self-describing data structure that is passed 
through by the service broker. This can be used by 
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Variable 


Description 




the buyer and supplier applications to exchange 
service specific data without needing a protocol 
change. 



Figure 7 provides an additional view of this interaction. In practice of the RoundTrip 
embodiment, the broker 703, at the service list selection URL receives the buyer's request for 
a list of available services 721 . Upon receiving this request, the broker consults its database 

5 to determine the set of services to which the buyer with the given OrgID is subscribed 722. It 
saves the user session context for later use 723. It returns this list of services to the buyer's 
browser, as an HTTP/S Reply 724. The buyer selects a service from the list of services 730 . 
This causes the browser to send an HTTP/Get or Post request 730 to the procurement 
application, which in turn does an HTTP/S Post 731 to the RoundTrip broker, to send to it, 

10 over an HTTP/S connection, the service selected, along with the supplier assigned 

userid/password. The broker looks up the URL of the selected service 732, gathers context 
data for use in the supplier session 733 and creates data structures to support the supplier 
session 734. In particular, in the RoundTrip embodiment, the broker creates the Service 
Session Start request document 734, and forwards it 735 over an HTTP/S connection, to the 

15 supplier 705. The supplier caches the data, performs a redirect, and then sends an HTTP/S 
Reply to the broker 737, who forwards the reply 738 on to the buyer 702. The broker 703 
can log the session 739. 

Figures 7 and 5 portray processes including supplier service selection and supplier 
service session start. The buyer 230 transmits the service selection to the broker application 

20 or e-commerce hub 210. The broker processes the selection and generates a supplier service 
session start document which it transmits to the supplier 240. 

When the user selects a specific service URL, the Service Broker sends a "Supplier 
Service Session Start" request to the chosen service's supplier application. The service 
context data is delivered to the supplier application via an HTTP Post to the URL 

25 (ServiceURL) specified by the supplier during registration. This is the initial communication 
between the broker application and the service application. In the RoundTrip embodiment, 
data is delivered as an XML format document within a hidden form field. The name of the 
hidden field typically is the name of the root element tag in the document being sent - for 
example, RTServiceStart, RTServiceEnd, RTServiceCancel, and RTServiceError. The 

30 general form for conveying the hidden field can use the following syntax: 
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<FORM ... 

< hidden name-'RTServiceStart" value ="<XML document . . . 

> 

In greater detail, the following schema depicts one embodiment of a supplier service 
session start document. Both the specific schema and some common schema information 
used in conjunction with the specific schema are provided. 

<?xml version="1 < 0 ,, ?> 
<!DOCTYPE schema SYSTEM 

"urnixcommerceoneidocumentxomicommerceoneixdkixmlrschema.dtdSI.O^ 
<schema uri= M urn:x- 

commerceone:document:com:commerceone:roundtrip:schemas:RoundTripServ 
iceStart.sox$1 .0"> 

<comment> 

Copyright 1999 Commerce One Inc. 
</comment> 

<namespace prefix-'cbl 11 namespace= M urn:x-commerceone:document:com: 
commerceone:CBL:CBL.sox$1 .07> 

<namespace prefix-'common" namespace="urn:x-commerceone:document: 
com:commerceone:roundtrip:RoundTripCommonTypes.sox$1.07> 

<elementtype name= n RTServiceStart"> 
<model> 

<sequence> 

<element prefix-'common" 
type= M DocumentExchangeProtocollnformation7> 
<element prefix-'common" type- 'Session Info 7> 

<element type="Loginlnfo7> 
<element name^TimeOut" type- 'inf occurs="?7> 
<element prefix-'cbl" name= M Language H type- 'LangCode" occurs="?7> 
<element prefix-'cbl" name="Currency M type="CurrencyCode M occurs= w ?7> 
<element prefix="cbl" name="Country" type="CountryCode n occurs="?7> 

<element name="BuyerApplnfo" prefix- 'common" type="Applicationlnfo" 
occurs="?7> 

<element prefix-'common" type- 'AcceptlnfoType7> 
<element prefix-'common" type- 'Cancel lnfoType"/> 
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<element prefix="common" type="URLDataType" name="ErrorURL" 
occurs="?7> 

<element prefix="common" type="PassThruData" occurs="?7> 
<element name= n SupplierPartNum" type="LimitedString" 
occurs="?7> 

<element name="SupplierlD" type= n LimitedString" occurs="?7> 
<element name="SupplieriDAgency" type="LimitedString" 
occurs="?7> 

<element name="SupplierAssignedAccountNum" 
type="LimitedString ,, occurs="?7> 
</sequence> 
</model> 
</elementtype> 

<elementtype name="Loginlnfo H > 
<explain> 

<p>The <code>Loginlnfo</code> contains the 
authentication data for signing onto the RoundTrip 
services.</p> 
</explain> 
<model> 
<sequence> 

<element name= M UserlD" type=TimitedString" occurs="?7> 
<element name="Password" type= ,, LimitedString ,, occurs- 77> 
<element name^OrglD" type="LimitedString7> 
<element name="OrglDAgency M type= M LimitedString" occurs="?7> 
</sequence> 
</model> 
</elementtype> 

</schema> 



Common Types 

<?xml version="1.CT?> 

<!DOCTYPE schema SYSTEM "urnix-commerceoneidocumentcom: 

commerceone:xdk:xml:schema.dtd$1.0"> 

<schema uri="urn:x-commerceone:docurnent:com:commerceone: 

roundtrip:schemas:RoundTripCommonTypes.sox$1.0 M > 

<comment> Copyright 1999 Commerce One Inc. </comment> 
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<comment> Accetplnfo and Cancellnfo should use a common datatype which 
could be Actionlnfo 

</comment> 

<elementtype name= u AcceptlnfoType"> 
<model> 
<sequence> 

<element type-'NameDataType" name= w Label7> 
<element type="URLDataType" name="URL M /> 
</sequence> 
</model> 
</elementtype> 

<elementtype name="CancellnfoType"> 
<model> 
<sequence> 

<element iype="NameDataType M name= f, Label7> 
<element type="URLDataType" name="URL M /> 
</sequence> 
</model> 
</elementtype> 

<elementtype name- 'ScreenSize"> 
<model> 

<element name^'HorizontalSize" type="int7> 

<element name="VerticalSize M type= M int7> 
</model> 
</elementtype> 

<elementtype name= H Sessionlnfo"> 
<model> 

<element type="SessionContext" type="string" occurs="?7> 
</model> 

<attdef name^'SessionlD" datatype= n UUlD"> 
<required/> 

<explain> 

<p>This is the service session id assigned by the broker. </p> 
</explain> 

</attdef> 
</elementtype> 



16 



WO 02/47005 



PCT/US01/47250 



<elementtype name="PassThruData"> 
<explain> 

<p>A place holder element for any other data that is 
required by the application to process the document(s) and 
other information returned in the BrokerSessionEnd.</p> 
<p><code>Content</code> - Format to be defined by the 
application. Note it cannot be in XML format (XML data can 
be URL encoded or otherwise encoded). </p> 
</explain> 

<model> 

<element name="Blob" type="string7> 
</model> 
</elementtype> 

<elementtype name="DocumentExchangeProtocollnformation"> 
<empty/> 

<attdef name="Protocol" datatype="LimitedString"> 

<default>RoundTrip</default> 
</attdef> 

<attdef name="ProtocolVersion" datatype="LimitedString"> 
<default>1.0</default> 
</attdef> 
</elementtype> 

<elementtype name="Name"> 
<model> 

<element name="NameString" type="NameDataType7> 
</model> 
</elementtype> 

<datatype name="NameDataType"> 
<varchar maxlength="50" datatype="string7> 
</datatype> 

<datatype name="LimitedString"> 
<varchar maxlength="80" datatype="string'7> 
</datatype> 

<elementtype name="Applicationlnfo"> 
<model> 
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<element name- 'AppFrameSize" type= w ScreenSize" occurs="?7> 
</model> 

<attdef name= n AppName M datatype="string"> 

<required/> 
</attdef> 

<attdef name= n AppVersiorT datatype= M string M > 

<required/> 
</attdef> 
</elementtype> 

<datatype name= ,, UUID"> 

<varchar maxlength="64 M datatype="string7> 
</datatype> 

<datatype name="URLDataType"> 
<varchar maxlength= ,, 256 M datatype="string n /> 
</datatype> 

<datatype name="URNDataType M > 
<varchar maxlength="256" datatype= M string7> 
</datatype> 

</schema> 

The following table explains some of the data items included in the supplier service 
session start XML document. In this table, the Supplier Service Session Start data is 
categorized. Session data is MarketSite Service Broker session information. Data such as 
session id is used by the broker application to associate the acquired data (order details) with 
a supplier service session. Other data, such as language, is provided as a courtesy so that the 
web-based service can provided a tailored experience. Authentication data includes 
information such as the organization's user-id and password. Authorization data, for catalogs 
and configurators, for instance, includes the buyer's supplier assigned account number or 
customer number. Parameter data provides information required by the supplier's service 
application. For example, a configurator will need a supplier part number. Parameter data 
typically can be provided by the buyer application. Finally, action data includes button labels 
and URLs for accept, cancel and other actions. 
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Variable 


Category 


Description 


DocumentExchange 
Prntnr n 1 Tn form ati on 


Session 


Specifies the document exchange protocol and 
version used, e.g., 'TloundTrip" and the 
version is 1.0. 


OCOoiLrlLLL/ 


Session 


This client session id (UUDD) allows the 
Roundtrip broker to associate the incoming 
configuration data (via Accept URL) with the 
supplier service and the buyer that performed 
the action. 


TimeOut 


Session 


Client session timeout value in minutes is 
optional. 


T an (ni op 

i-iCXl IgUd^t 


Session 


The user preferred two-letter ISO language 
code. Reference CBL element LangCode. 




Session 


Reference CBL element CurrencyCode is 
optional. 


Country 


Session 


Can be used to determine/guess the number 
and date formats. Reference CBL element 
CountryCode, 


BuyerAppName 


Session 


Buyer application name/id. 


BuyerAppVersion 


Session 


Buyer application version. 


RnverAnnFrameSize 


Session 


Buyer application's frame size. 

m \T J FK . — =■ =— = 




Authentication 


Used for implicit login. This means that the 
userid is on a per buying organization 
registered service basis. 


Password 


Authentication 


Used for implicit login. This means that the 
password is on a per buying organization 
registered sendee basis. 


OrgID 


Authentication 




OrglDAgency 


Authentication 




AcceptURL 


Action 


A URL to a MarketSite ASP/servlet/CGI for 
processing the configured order. 


AcceptLabel 


Action 


This is the button label that the trading partner 
web-based services will associate with the 
Accept URL. 


CancelURL 


Action 


A URL to a MarketSite ASP/servlet/CGI for 
handling the user canceling the configurator 
process. 


CancelLabel 


Action 


This is the button label that the suppliers will 
associate with the Cancel URL. 


ErrorURL 


Action 


A URL to a MarketSite servlet for displaying j 
errors. ! 


PassThruData 


Parameter 


This parameter is passed through by the 
service broker. This can be used by the buyer 
and supplier applications to exchange service 
specific data that are not accounted for in the 
protocol. This would enable such buyers and 
1 suppliers to integrate without having to wait 
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Variable 


Category 


Description 






for a protocol change. 



The previous table shows a basic supplier service session start data layout. The following 
table shows a list of additional supplier specific data items that can be part of the RoundTrip 
Supplier Service Start document: 



Variable 


Category 


Description 


SupplierPartNum 


Parameter 


Used by web-based configurators. 


SupplierED 


Parameter 


While not required if connecting directly 
to a supplier, probably useful if 
connecting an intermediate trading 
partner. 


SupplierEDAgency 


Parameter 


Used to identify the agency that created 
any identifiers (e.g. Supplier ID and 
Supplier Account Number) in this 
information set. 


SupplierAssignedAccount 
Num 


Parameter 


For the supplier-based services, this is the 
customer number assigned by the supplier 
to the buying organization. This 
facilitates contract pricing. 



The following example provides a document consistent with the schema above. 



<?xml version="1 .0"?> 
10 <?soxtype urn:x-commerceone:document:com:commerceone:roundtrip:schemas: 
RoundTripServiceStart.sox$1 .0?> 
<RTServiceStart 

xmlns:common="urn:x- 
commercone:document:com:commerceone:roundtrip:schemas: 
15 RoundTripCommonTypes.sox$1 .0" 

xmlns:cbl="urn:x-commerceone:document:com:commerceone: 
CBL:CBL.sox$1.0"> 
<common:DocumentExchangeProtocollnformation Protocol-'RoundTrip" 
ProtocolVersion="1 .07> 
20 <common:Sessionlnfo SessionlD="CF543873-D7B9-1 1 D3-830B- 

00609709DDA17> 
<Loginlnfo> 

<UserlD>123456</UserlD> 
<Password>my password</Password> 
25 <OrglD>buyer organization id</OrglD> 

Org IDAgency>MarketSite. net</Org I DAge ncy> 
</Loginlnfo> 

<TimeOut>10</TimeOut> 
<Language>en</Language> 
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<Currency>USD</Currency> 
<Country>US</Country> 

<BuyerApplnfo AppName="BuySite" AppVersion="6.0"> 
<common:AppFrameSize> 
5 <common:ScreenSize> 

<common:Hori2ontalSize>600</common:Hori2ontalSize> 
<common:VerticalSize>800</common:VerticalSize> 
</common:ScreenSize> 
</common:AppFrameSize> 
10 </BuyerApplnfo> 

<common:AcceptlnfoType> 
<common:Label>Order</common:Label> 
<common : U RL>http ://www. marketsite . ne t/servlet/e nd</common:URL> 
</common: Accept! nfoType> 
15 <common:CancellnfoType> 

<comrnon:LabeI>Cancel</common:Label> 
<common:URL>http://www^ 
</common:CancellrifoType> 
<ErrorURL>http://v\A^ 

20 <SupplierAssignedAccountNum>4356</SupplierAssignedAccountNum> 
</RTServiceStart> 

Figure 2 depicts the supplier service session and direct buyer to supplier interaction 
250. The buyer and supplier communicate directly with each other, without need for broker 

25 involvement, monitoring or logging. In other embodiments, the broker can forward many or 
all of the messages between the buyer and supplier, thereby enabling the broker application to 
log all or some aspects of the interaction to facilitate error recovery. 

When the buyer is done with the supplier site, he may select a Submit or Cancel button in 
the browser. These selections lead to generation of a Service Session End or Service Session 

30 Cancel XML document, respectively, which is to be sent to the buyer by the supplier via the 
broker, as a hidden form field, over HTTP/S Post. The supplier service posts to a URL 
(CallBackURL) specified in the Supplier Service Session Start data. The data in this the 
posted document include Supplier Service Session End data as an XML document within a 
hidden form field, consistent with the following schema. The supplier's document also 

35 includes an order response (e.g., a shopping cart) as a CBL format document within a hidden 
form field. A schema for and example of a shopping cart response follow. The Service 
Session End document is sent to a buyer provided Submit URL. Alternatively, a Service 
Session Cancel document is sent to a buyer provided Cancel URL. The buyer receives and 
processes these documents. 
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Any errors that occur during this interaction may be posted to a specified error URL. 
These errors can be automatically displayed within the buyer' s browser. 

The supplier service session end document is an HTTP form is posted to the broker 
callback URL when the Supplier Service Session Ends. This form contains the "Supplier 
Service Session End" XML document and a List of Order Details CBL documents in hidden 
fields. The following syntax is used: 

<FORM ACTION="http://roundtrip.marketsite.net/servlet/end" 
METHOD="POST" 
NAME="CallBackDialog"> 
<INPUT TYPE="HIDDEN" NAME-'RTServiceEnd" 
VALUE="<?xml version="1.0"?> 

this is an HTML encoded RTServiceEnd document 
"> 

</FORM> 

The following schema depicts a supplier service session end document 

<?xmlversion="1.0"?> 

<!DOCTYPE schema SYSTEM "urn:x- 

commerceone:document:com:commerceone:xdk:xml:schema.dtd$1.0"> 
<schema uri="urn:x- 

commerceone:document:roundtrip:schemas:RoundTripServiceEnd.sox$1.0"> 
<comment> 

Copyright 1999 Commerce One Inc. 
</comment> 

<namespace prefix="cbl H namespace="urn:x- 
commerceone:document:com:commerceone:CBL:CBL.sox$1.07> 

<namespace prefix="common" namespace="urn:x- 
commerceone:document:com:commerceone:roundtrip:RoundTripCommonT 

ypes.sox$1.07> 

<elementtype name="RTServiceEnd"> 

<model> 

<sequence> 

<element prefix="common" 
type="DocumentExchangeProtocollnformation7> 

<element prefix="common" type="Sessionlnfo7> 
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<element prefix= M cbr name="Language" type="LangCode" occurs="?7> 

<element prefix="cbl" name="Currency" type="CurrencyCode" 
occurs="?7> 

<element prefix="cbr name="Country M type="CountryCode" occurs="?7> 
<element type- *ResponseData7> 

<element prefix-'common" type-'PassThruData" occurs="?7> 
<element name="RequestEcho" type="RTServiceStart" occurs="?7> 
</sequence> 
</model> 
</elementtype> 

<elementtype name="ResponseData"> 
<empty/> 

<attdef name= n ResponseDataType" datatype="LimitedString"> 

<required/> 
</attdef> 

<attdef name="ResponseDataFormat M datatype= M LimitedString7> 

<required/> 
</attdef> 

<attdef name="ResponseDataFormatVersion" datatype= M LimitedString7> 

<required/> 
</attdef> 
</elementtype> 

<elementtype name="ShoppingCart n > 
<explain> 

<p>A <code>ShoppingCart</code> is typically returned from a 
RoundTrip session with a supplier's catalog or configurator. 
The <code>ShoppingCart</code> will contain an <code> 
OrderRequest</code>.</p> 

<p><code>OrderRequest</code> - an order request containing the 
items selected by and/or configured by the user from the supplier's 
web based catalog/configurator.</p> 
</explain> 

<extends type^'ResponseData'^ 
<append> 

<element name="CartlD" type="LimitedString7> 
<element prefix-'cbl" type= M OrderRequest7> 
</append> 
</extends> 
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</elementtype> 
</schema> 

In this schema, the ResponseData element enables polymorphism of the session end data 

5 document. The extension of ResponseData is self-describing. That is, the basic attributes of 
ResponseData, which may be extended and adapted in various embodiments, describe the 
extended data attributes. Data type and version attributes allow the buyer application to 
determine what data is associated with the message. An optional data format attribute 
permits further definition of the data associated with the message. This is an extension of 

10 XML. The same message, with variants, can be adapted to a variety of functions, such as 
conveying reference to or the values of shopping cart data, conveying product configuration 
data, conveying tax calculation data or conveying shipping or foreign freight forwarding data. 
Use of a polymorphic data schema decouples programming from the evolution of document 
types and applications. Use of namespaces supports coordination of document type names, 

15 development, deployment and maintenance of applications. Relative to a namespace, a 
schema identifier is provided with a message, which is resolvable in a context of a system 
identifier, hi the sample schemas herein, the system identifier is explicit and part of the self- 
describing data. The system identifier may be universally unique, across the namespace of 
the Internet, or locally unique in some narrower domain. At some sacrifice of general 

20 adaptability, the system identifier may be implicit in the data tables or program code used by 
the buyer or supplier application or it may be implicit in the choice of a narrower domain 
than the Internet. Other Sox extensions of XML which are useful in practicing aspects of the 
present invention are support of typed data, a predefined set of intrinsic types, such as string, 
int, URI, and date, user defined types based on enumerated, scalar, and varchar type 

25 definitions, namespaces and versions for schemas, and an extensibility mechanism that 

facilitates the reuse and evolution of schemas and element types. Translation of Sox to Java 
data formats can leverage strong typing and data structures which are readily mapped into 
Java. 

Polymorphism is not limited in this invention to responses from a supplier. Responses 
30 from a buyer to a supplier also can take advantage of this method and data structure. 

Alternatively, polymorphism can be used at the outset of a session, in a first message (not 
necessarily the actual first message) from the initiating party to the broker. Either the buyer 
or supplier can initiate a session through the broker and use polymorphism during the 
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initiating. For example, a buyer can initiate a status inquiry or a purchase order start using 
data structures equivalent to ResponseData, in place of PassThroughData. A supplier can 
initiate a session, reversing the roles of the schemas or messages offered as examples herein, 
and use polymorphism during the initiating. This may be useful to a supplier for purchase 

5 order responses, invoices or advance shipment notices. At the conclusion of a session 
initiated by a supplier, the buyer may respond with data regarding changed conditions. 
Alternate schedules or other delivery information can be provided. Alternate configurations 
can be provided if a selected configuration has become unavailable. 

The following table explains some data items that are part of the Supplier Service 

10 Session End document: 



Variable 


Category 


Description 


DocumentExchangeProtoc 
ollnformation 


Session 


Specifies the document exchange 
protocol and version used, e.g., 
"RoundTrip" and the version is 1 .0. 


SessionED 


Session 


Same as the Session ID provided as 
part of the Session Start. 


T antrum up 


Session 


Useful if the result data contains a 
language specific text without a 
specified language code and the 
language text in the result data is 
different than "Language" specified 
in the RoundTrip context. The user 
preferred two-letter ISO language 
code. 


Currency 


Session 


Useful if the result data contains a 
monetary amount without a specified 
currency code and the currency in 
the result data is different than 
"Currency" specified in the 
RoundTrip context. 


Country 


Session 


Useful if the result data contains any 
country specific formatted data 
without a specified country code and 
the country specific formatted data 
in the result data is different than 
"Country" specified in the 
RoundTrip context. Reference CBL 
element CountryCode. 


ResponseDataFormat 


Response 


The Session End data format 


ResponseDataFormatVers 
ion 


Response 


Version number of response data 
format, e.g., CBL 2.0. 


ResponseData 


Response 


Polymorphic data element, ! 
supporting shopping cart and other 
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Variable 


Category 


Description 






functions. 


ResponseDataType 


Response 


Specifies the type of Response Data. 


PassThmData 




Used by the buyer and supplier 
applications to exchange service 
specific data that are not accounted 
for in the protocol. This would 
enable such buyers and suppliers to 
integrate without having to wait for a 
protocol change. 


RequestEcho 


Parameter 


Echo back of original request. 
Provided for sanity checking - if the 
broker wants to process the Service 
End document according to data in 
the Service Start Request, for 
example. 



As an extension of ResponseData, the following schema supports a shopping cart. 



5 <?xml version="1 .0"?> 

<!DOCTYPE schema SYSTEM "urn:x-commerceone:document:com: 
commerceone:xdk:xml:schema.dtd$1.0"> 

<schema uri="um:x-commerceone:document:com: 
10 commerceone:CBL:CBL.sox$1 .0"> 

<intro> 

<M>Order Request</h1> 

15 <p>Copyright Notice</p> 

<p>Common Business Library 2.0<br/> 

Copyright 1999 Commerce One, lnc.</p> 

<p>Permission is granted to use, copy, modify and distribute the 

DTD's, schemas and modules in the Commerce One Common Business 
20 Library Version 2.0 subject to the terms and conditions specified 

at <tt>http.7/www.marketsite.net/xml/cbl/copyright.html</tt></p> 
</intro> 

<elementtype name="OrderRequest"> 
25 <model> 

<sequence> 

<element type="OrderRequestHeader'7> 
<elementtype="ListOfOrderRequestDetail'7> 
<elementtype="OrderRequestSummary7> 
30 </sequence> 
</model> 
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</elementtype> 

</schema> 

5 <?xml version=" 1 .0"?> 

<!DOCTYPE schema SYSTEM "um:x-commerceone:document:com: 
commerceone:xdk:xml:schema.dtd$1.0"> 

<schema uri="urn:x-commerceone:document:com: 
10 commerceone:CBL:CBL.sox$1.0"> 

<intro> 

<h1>Order Request Detail</h1> 

15 <p>Copyright Notice</p> 

<p>Common Business Library 2.0<br/> 

Copyright 1999 Commerce One, lnc.</p> 

<p>Permission is granted to use, copy, modify and distribute the 

DTD's, schemas and modules in the Commerce One Common Business 
20 Library Version 2.0 subject to the terms and conditions specified 

at <tt>http://www.marketsite.net/xml/cbl/copyright.html</tt></p> 
</intro> 

<elementtype name="OrderRequestDetail"> 
25 <model> 

<extends type="BaseltemDetail"> 
<append> 
<sequence> 

<element type="SupplierConfigNum" occurs="?7> 
30 <element type="string" name="GeneralNote" occurs="?7> 

<element type="Tax" occurs="?"/> 
<element type="ListOfAllowOrCharge" occurs="?7> 
<element type="Price" name="BuyerExpectedUnitPrice7> 
<elementtype="ListOfAttachment" name="OrderDetailAttachment" 

35 occurs="?7> 

<element type- 'boolean" name="lmmutable" occurs="?7> 
</sequence> 
</append> 
</extends> 
40 </model> 

</elementtype> 

<elementtype name="ListOfOrderRequestDetair> 
<model> 

45 <element type="OrderRequestDetail" occurs="+7> 

</model> 
</elementtype> 

</schema> 
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<?xml version= M 1.0"?> 

<!DOCTYPE schema SYSTEM "urn:x-commerceone:document:com: 
5 commerceone:xdk:xml:schema.dtd$1.0"> 

<schema uri="urn:x-commerceone:document:com: 
commerceone:CBL:CBL.sox$1 .0"> 

10 <intro> 

<h1>Order Request Header</h1> 

<p>Copyright Notice</p> 
<p>Common Business Library 2.0<br/> 

15 Copyright 1999 Commerce One, lnc.</p> 

<p>Permission is granted to use, copy, modify and distribute the 
DTD's, schemas and modules in the Commerce One Common Business 
Library Version 2.0 subject to the terms and conditions specified 
at <tt>http://www.marketsite.net/xml/cbl/copyright.html</tt></p> 

20 </intro> 

<elementtype name="OrderRequestHeader"> 
<model> 

<sequence> 

25 <element type="datetime" name="OrderRequestDate7> 

<element type="0rderRequestReference'7> 
<element type="OrderParty" occurs="?7> 
<element type=Tax" occurs="?7> 
<element type="CurrencyCode" name="OrderCurrency7> 
30 <element type="LangCode" name="OrderLanguage7> 

<element type="string" name="GeneralNote" occurs="?7> 
<element type="boolean" name="lmmutable" occurs="?'7> 
<element type="ListOfAttachment" 
name="OrderRequestHeaderAttachment"occurs= ,, ?7> 
35 </sequence> 
</model> 
</elementtype> 

</schema> 

40 

<?xml version="1.0"?> 

<!DOCTYPE schema SYSTEM "urn:x-commerceone:document:com: 
commerceoneixdkixmlrschema.dtdSI.O 

45 <schema uri="urn:x-commerceone:document:com: 
commerceone:CBL:CBL.sox$1 .0"> 

<intro> 

<h1>Order Request Reference</h1> 
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<p>Copyright Notice</p> 
<p>Common Business Library 2.0<br/> 
Copyright 1999 Commerce One, lnc.</p> 
5 <p>Permission is granted to use, copy, modify and distribute the 

DTD's, schemas and modules in the Commerce One Common Business 
Library Version 2.0 subject to the terms and conditions specified 
at <tt>http://www.marketsite.net/xml/cbl/copyright.html</tt></p> 

io <p>A collection of references that are used by 

<code>OrderRequest</code>. 
</intro> 

<elementtype name="OrderRequestReference"> 
15 <explain> 

<p><code>AccountCode</code> is the agreement number between a 
buyer and a supplier. An account may contain several contracts 
in it.</p> 

<pxcode>CustRefNum</code> is the Order Request identification 
20 number.</p> 

<p><code>BuyerRefNum</code> is Buyer's Purchase Order Num.</p> 
<p><code>SupplierRefNum</code> is Supplier's Order Num.</code> 
or Suppliers Sales Order Num.</p> 

<p><code>SupplierConfigNum</code> is a configuration number. </p> 
25 <p><code>ListOfReferenceCoded</code> - This is used for other 

references that a buyer want to provide to supplier, such as 
Buyer Catalog Reference Number, </p> 
</explain> 
<model> 
30 <sequence> 

<element type="Reference" name="AccountCode" occurs="?7> 
<element type="Reference" name="CustRefNum" occurs="?"/> 
<element type="Reference" name="BuyerRefNum" occurs="?7> 
<element type="Reference" name="SupplierRefNum" occurs="?7> 
35 <element type="Reference" name="SupplierConfigNum" occurs="?"/> 

<element type="ListOfReferenceCoded" occurs="?7> 
</sequence> 
</model> 
</elementtype> 

40 

</schema> 

<?xml version="1.0"?> 

<!DOCTYPE schema SYSTEM "urn:x-commerceone:document:com: 
45 commerceone:xdk:xml:schema.dtd$1 .0"> 

<schema uri="urn:x-commerceone:document:com: 
commerceone:CBL:CBL.sox$1 .0"> 
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<intro> 

<h1>Order Request Summary</h1> 

<p>Copyright Notice</p> 
<p>Common Business Library 2.0<br/> 
Copyright 1999 Commerce One, lnc.</p> 
<p>Permission is granted to use, copy, modify and distribute the 
DTD's, schemas and modules in the Commerce One Common Business 
Library Version 2.0 subject to the terms and conditions specified 
at <tt>http://www.marketsite.net/xml/cbl/copyright.html</tt></p> 
</intro> 

<elementtype name="OrderRequestSummary"> 
<model> 

<sequence> 

<element type= M Decimal1 8_3" name= n TotalAmount7> 
<element type="int" name="TotalLineNum" occurs="?7> 
</sequence> 
</model> 
</elementtype> 

</schema> 

An example of an end document extended by a shopping cart morphism 
follows: 

<?xml version="1.0"?> 
<?soxtype um:x- 

commerceone:document:com:commerceone:roundtrip:schemas:RoundTripServic 

eEnd.sox$1.0?> 

<RTServiceEnd 

xmlns:common="um:x- 

commercone:document:com:commerceone:roundtrip:schemas:RoundTripCommo 
nTypes.sox$1.0 M 

xmlns:cbl="urn:x- 
commerceone:document:com:commerceone:CBL:CBL.sox$1 ,0"> 
<common:DocumentExchangeProtocollnformation ProtocoKRoundTrip" 
ProtocolVersion="1.07> 

<common:SessionInfo SessionlD="CF543873-D7B9-1 1 D3-830B- 
00609709DDA17> 

<Language>en</Language> 
<Currency>USD</Currency> 
<Country>US</Country> 
<ShoppingCart ResponseDataFormat="CBL" 
ResponseDataFormatVersion="2.0 M ResponseDataType= M OrderRequest"> 
<CartlD>3456</CartlD> 
<OrderRequest xmlns= n urn:x-commerceone:document:com:commerceone: 
CBL:CBLsox$1.0"> 

<OrderRequestHeader> 
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<OrderRequestDate>1 9990531 T1 9:55:00</OrderRequestDate> 
<OrderRequestReference> 

<AccountCode><Reference><RefNum>CTOP</RefNum></Referenc 
e> </AccountCode> 

<BuyerRef NumxReferencexRef Num> 1 00</Ref Numx/Reference 
> 

</BuyerRefNum> 
<SupplierRefNum><Reference><RefNum>2</RefNum></Reference> 

</SupplierRefNum> 

</OrderRequestReference> 
<OrderParty> 

<BuyerParty><Party> 

<NameAddress> 

<Name1>Mr. Muljadi Sulistio</Name1> 

<Name2>Attention:Business Service Division</Name2> 

<Address1>1600 Riviera Ave.</Address1> 

<Address2>Suite #200</Address2> 

<City>Walnut Creek</City> 

<State>CA</State> 

<PostalCode>94596</PostalCode> 

<Country>US</Country> 

</NameAddress> 

<OrderContact> 

<Contact> 

<ContactName>Mr. Muljadi Sulistip</ContactName> 
<Telephone>(650) 932-4555</Telephone> 
<Email>mike.holloway@commerceone.corn</Email> 
<Fax>(650) 468-8900</Fax> 

</Contact> 

</OrderContact> 
<ReceivingContact> 

<Contact> 

<ContactName>Mr. Debbie Dub</ContactName> 
<Telephone>(650) 932-4555</Telephone> 
<Email>debbie.dub@cornmerceone.com</Email> 
<Fax>(650) 468-8900</Fax> 

</Contact> 

</ReceivingContact> 
<ShippingContact> 

<Contact> 

<ContactName>Mr.John Wayne</ContactName> 
<Telephone>(650) 932-4555</Telephone> 
<Email>john.wayne@commerceone.com</Email> 
<Fax>(650) 468-8900</Fax> 

</Contact> 

</ShippingContact> 

</Party></BuyerParty> 

<SupplierParty><Party> 
<NameAddress> 
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<Name1 >Millenium Supplier</Name1 > 
<Name2>Attention: Office Supply Division</Name2> 
<Address1>1600 Riviera Ave.</Address1 > 
<Address2>Suite #200</Address2> 
<City>Walnut Creek</City> 
<State>CA<State> 
<PostalCode>94596</PostalCode> 
<Country>US</Country> 
</NameAddress> 
</Party></SupplierParty> 
</OrderParty> 

<OrderCurrency>USD</OrderCurrency> 
<0rderLanguage>EN</0rderl_anguage> 
</OrderRequestHeader> 
<ListOfOrderRequestDetail> 
<OrderRequestDetail> 

<LineltemNum>1 </LineltemNum> 

<SupplierPartNum> 

<PartNum> 

<Agency>AssignedBySupplier</Agency> 

<PartlD>12345</PartlD> 

</PartNum> 

</SupplierPartNum> 

<ltemDescription>Sanford Highlighting 
Marker</ltemDescription> 

<Quantity> 
<Qty>00000000000 1 .000</Qty> 
<UnitOfMeasure>EA</UnitOfMeasure> 
</Quantity> 

<Transport Direction="SupplierToBuyer"> 
<Mode>Air</Mode> 
<Mean>Express</Mean> 
<Carrier>Fedex</Carrier> 

<CustShippingContractNum>CTOP1 23</CustShippingContractNum> 
<Shippinglnstruction>Please handle with care 
</Shippinglnstruction> 
</Transport> 

<OffCatalogFlag>false</OffCatalogFlag> 
<BuyerExpectedUnitPrice> 

<Price><UnitPrice>00000000010.0000</UnitPrice></Price> 

</BuyerExpectedUnitPrice> 

</OrderRequestDetail> 
</ListOfOrderRequestDetail> 
<OrderRequestSummary> 

<TotalAmount>000000000001000.000</TotalAmount> 

<TotalLineNum>1 </TotalLineNum> 

</OrderRequestSummary> 
</OrderRequest> 
</ShoppingCart> 
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</RTServiceEnd> 

Figure 6 depicts a sequence ending the broker session, upon completion of the supplier 
service session. Once the buyer 230A is done, an order or cancel button is selected at the 
5 buyer browser. This generates an HTTP/S Post of a service session end document to the 
broker application. The broker sends it through the LI component 413 to a forwarding 
component of the L2 component 416. The forwarding component processes the data, 
receives a service session end document from the supplier application, forwards the 
document to the buyer's procurement application 230B, receives a reply, and forwards the 
10 reply to the buyer for display in the buyer's browser or other viewing software 230A. In the 
context of the present invention, the buyer application can refer to the buyer's browser, the 
procurement application or both. When the service interaction completes and the supplier 
sends a "Supplier Service Session End" request to the broker, the broker processes the 
"Supplier Service Session End" message and generates an HTTP post to the buyer callback 
1 5 URL that was specified by the buyer during registration. The data in this communication 
contains the supplier service session end data as an XML document within a hidden form 
field. As described above, in the instance of a shopping cart session, the order details 
(shopping cart) as a CBL format document within a hidden form field. 

An example of one embodiment practicing aspects of the present invention begins when a 
20 user web browser is displaying ABC Motors Product Search page in which one or more 

motors have been selected. The user reads and selects one or more items. The user clicks on 
an "Order Form" link to submit the request. The ABC Motors order form page is served up 
by the ABC Motors server. The "Check Out" button sometimes used in e-commerce is 
replaced with the buyer application specified "Accept" button label. For example, the actual 
25 label may read "Add To a Requisition." The user clicks on the "Accept" button. This results 
in a HTTP/S Post to the ABC Motors server. The web browser is waiting for an HTTP 
Reply. The ABC Motors server HTTP/S Posts to the broker application the OrderRequest 
and context earlier provided by the broker application. The ABC Motors server is waiting 
for an HTTP Reply. The broker application HTTP/S Posts to the appropriate buyer 
30 application "Accept Order Request" ASP page for receiving the OrderRequest CBL and 
earlier provided buyer application context. The broker application is waiting for an HTTP 
Reply. The buyer application "Accept Order Request" ASP addes the items in the 
OrderRequest to the user's requisition (the buyer application context contains the user session 
information) and then HTTP/S Replies with HTML (to the broker application). The broker 
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application HTTP/S Replies with the buyer application provided HTML to the ABC Motors 
server. The ABC Motors server HTTP/S Replies with the buyer application provided HTML 
to the user's web browser. The user's web browser refreshes per the HTML. 

Due to the polymorphic nature of the message used to conclude the buyer-supplier 
session, the message is suitable for a variety of divers applications, including product 
configuration, tax calculations or freight forward, in addition to this shopping cart example. 
A further example of a tax calculation extension to ResponseData follows: 

<elementtype name= , TaxCa!culation"> 
<explain> 

<p>A <code>Tax</code> is typically returned from a 
RoundTrip session with a supplier's catalog or configurator. 
The <code>ShoppingCart</code> will containan <code> 
OrderRequest</code>.</p> 

<p><code>OrderRequest</code> - an order request containing the 
items selected by and/or configured by the user from the supplier's 
web based catalog/configurator. </p> 
</explain> 

<extends type= H ResponseData"> 
<append> 

<element prefix="cbl" type="Tax7> 
</append> 
</extends> 
</elementtype> 
</schema> 

Additional aspects of a system practicing the present invention may include forwarding a 
purchase order, as depicted in figure 2. Cancellation and error messages, referred to above, 
are described by schemas following the general form of the schemas presented in the 
examples. 

It is inherent in the present invention that methods practicing the present invention can 
be expressed as articles of manufacture by describing the method as embodied in a program 
stored on a magnetic medium. It is further inherent that those methods can be expressed as a 
broker server device running the broker portion of the method or as a system including buyer, 
broker and supplier servers running their respective portions of the method. 

While the present invention is disclosed by reference to the embodiments and examples 
detailed above, it is understood that these examples are intended in an illustrative rather than 
in a limiting sense. It is contemplated that modifications and combinations will readily occur 
to those skilled in the art, which modifications and combinations will be within the spirit of 
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the invention and the scope of the following claims. Each method practicing the present 
invention may readily be recast as a device or article of manufacture. 
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Claims 

What is claimed is: 

1 . A protocol for conveying data during an e-commerce session with a polymorphic 
response, comprising: 

initiating a session with a first message from a buyer application to a broker 
application and a second message from the broker application to a supplier 
application; 

conducting the session between the buyer application and the supplier 
application; and 

responding during the session with an additional message including: 

a schema identifier for the additional message, resolvable in a context 
of a system identifier; and 

a polymorphic response comprising a type and a version, wherein the 
polymorphic response including additional data elements 
corresponding to values assigned to the type and version. 

2. The protocol of claim 1, wherein the system identifier is explicit in the additional 
message. 

3. The protocol of claim 1 , wherein the system identifier for the additional message 
is implicit. 

4. The protocol of claim 1 , wherein the buyer application comprises a browser. 
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5. The protocol of claim 1, wherein the buyer application comprises a procurement 
application. 

6. The protocol of claim 1 > wherein the buyer application comprises a browser and a 
procurement application. 

7. The protocol of claim 1, wherein the second message forwards at least a portion of 
the first message. 

8. The protocol of claim 1, wherein conducting the session between the buyer 
application and the supplier application includes direct communications between 
the respective applications. 

9. The protocol of claim 1, wherein conducting the session between the buyer 
application and the supplier application includes communications between the 
respective applications through the broker application. 

10. The protocol of claim 1=, wherein the polymorphic response is represented in an 
extension of XML. 

11. The protocol of claim 1, wherein the polymorphic response is represented in a 
form compatible with Sox. 

12. The protocol of claim 1, wherein the additional message is sent by the supplier 
application to the broker application. 

13. The protocol of claim 12, wherein the additional message is forwarded by the 
broker application to the buyer application. 

14. The protocol of claim 12, further including the broker application translating a 
supplier's format of the additional data elements to a buyer's format of the 
additional data elements. 
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15. The protocol of claim 13, further including the broker application translating a 
supplier's format of the additional data elements to a buyer's format of the 
additional data elements. 

1 6. The protocol of claim 12, wherein the additional message includes price and 
destination information and the broker application calculates tax applicable to the 
price and destination information. 

17. The protocol of claim 13, wherein the additional message includes price and 
destination information and the broker application calculates tax applicable to the 
price and destination information. 

18. The protocol of claim 1 , wherein the system identifier comprises a universal 
resource name. 

19. The protocol of claim 1, wherein the additional data elements of the polymorphic 
response are adapted to transmitting a shopping basket identifier from the supplier 
to the buyer. 

20. The protocol of claim 12, wherein the additional data elements of the polymorphic 
response are adapted to transmitting a shopping basket identifier from the supplier 
to the buyer. 

21. The protocol of claim 1, wherein the additional data elements of the polymorphic 
response are adapted to transmitting a shopping basket data set from the supplier 
to the buyer. 

22. The protocol of claim 12, wherein the additional data elements of the polymorphic 
response are adapted to transmitting a shopping basket data set from the supplier 
to the buyer. 
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23. The protocol of claim 1, wherein the additional data elements of the polymorphic 
response are adapted to transmitting product configuration data. 

24. The protocol of claim 12, wherein the additional data elements of the polymorphic 
response are adapted to transmitting product configuration data. 

25. The protocol of claim 1, wherein the additional data elements of the polymorphic 
response are adapted to transmitting tax calculation data. 

26. The protocol of claim 12, wherein the additional data elements of the polymorphic 
response are adapted to transmitting tax calculation data. 

27. The protocol of claim 1, wherein the additional data elements of the polymorphic 
response are adapted to transmitting freight forwarding data. 

28. The protocol of claim 12, wherein the additional data elements of the polymorphic 
response are adapted to transmitting freight forwarding data. 

29. A protocol for conveying data during an e-commerce session with a polymorphic 
response, comprising: 

initiating a session with a first message from a supplier application to a broker 
application and a second message from the broker application to a buyer 
application; 

conducting the session between the buyer application and the supplier 
application; and 

responding during the session with an additional message including: 

a schema identifier for the additional message, resolvable in a context 
of a system identifier; and 
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a polymorphic response comprising a type and a version, wherein the 
polymorphic response including additional data elements 
corresponding to values assigned to the type and version. 

30. The protocol of claim 29, wherein the system identifier is explicit in the additional 
message. 

31. The protocol of claim 29, wherein the system identifier for the additional message 
is implicit. 

32. The protocol of claim 29, wherein the buyer application comprises a browser. 

33. The protocol of claim 29, wherein the buyer application comprises a procurement 
application. 

34. The protocol of claim 29, wherein the buyer application comprises a browser and 
a procurement application. 



35. The protocol of claim 29, wherein the second message forwards at least a portion 
of the first message. 



36. The protocol of claim 29, wherein conducting the session between the buyer 
application and the supplier application includes direct communications between 
the respective applications. 

37. The protocol of claim 29, wherein conducting the session between the buyer 
application and the supplier application includes communications between the 
respective applications through the broker application. 

38. The protocol of claim 29, wherein the polymorphic response is represented an 
extension of XML. 
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39. The protocol of claim 29, wherein the polymorphic response is compatible with 
Sox. 

40. The protocol of claim 29, wherein the additional message is sent by the supplier 
application to the broker application. 

41. The protocol of claim 40, wherein the additional message is forwarded by the 
broker application to the buyer application. 

42. The protocol of claim 40, further including the broker application translating a 
supplier's format of the additional data elements to a buyer's format of the 
additional data elements. 

43. The protocol of claim 41, further including the broker application translating a 
supplier's format of the additional data elements to a buyer's format of the 
additional data elements. 

44. The protocol of claim 40, wherein the additional message includes price and 
destination information and the broker application calculates tax applicable to the 
price and destination information. 

45. The protocol of claim 41, wherein the additional message includes price and 
destination information and the broker application calculates tax applicable to the 
price and destination information. 

46. The protocol of claim 29, wherein the system identifier comprises a universal 
resource name. 

47. A protocol for conveying data during an e-commerce session with a polymorphic 
message, comprising: 

initiating a session with a first message from a buyer application to a broker 
application including: 
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a schema identifier for the first message, resolvable in a context of a 
system identifier; and 

a polymorphic message comprising a type and a version, wherein the 
polymorphic message including additional data elements 
corresponding to values assigned to the type and version; 

sending a second message from the broker application to a supplier 
application; and 

conducting the session between the buyer application and the supplier 
application. 

48. The protocol of claim 47, wherein the system identifier is explicit in the additional 
message. 

49. The protocol of claim 47, wherein the system identifier for the additional message 
is implicit. 

50. The protocol of claim 47, wherein the buyer application comprises a browser. 

51. The protocol of claim 47, wherein the buyer application comprises a procurement 
application. 

52. The protocol of claim 47, wherein the buyer application comprises a browser and 
a procurement application. 

53. The protocol of claim 47, wherein the second message forwards at least a portion 
of the first message. 

54. The protocol of claim 47, wherein conducting the session between the buyer 
application and the supplier application includes direct communications between 



42 



WO 02/47005 



PCT/US01/47250 



the respective applications. 

55. The protocol of claim 47, wherein conducting the session between the buyer 
application and the supplier application includes communications between the 
respective applications through the broker application. 

56. The protocol of claim 47, wherein the polymorphic response is represented in an 
extension of XML. 

57. The protocol of claim 47, wherein the polymorphic response is represented in a 
form compatible with Sox. 

58. The protocol of claim 47, further including the broker application translating a 
buyer's format of the additional data elements to a supplier's format of the 
additional data elements. 

59. The protocol of claim 47, wherein the system identifier comprises a universal 
resource name. 

60. The protocol of claim 47, wherein the additional data elements of the polymorphic 
message are adapted to transmitting status inquiry data. 

61. The protocol of claim 53, wherein the additional data elements of the polymorphic 
message are adapted to transmitting status inquiry data. 

62. The protocol of claim 47, wherein the additional data elements of the polymorphic 
message are adapted to transmitting purchase order data. 

63. The protocol of claim 53, wherein the additional data elements of the polymorphic 
message are adapted to transmitting purchase order data. 
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64. A protocol for conveying data during an e-commerce session with a polymorphic, 
message, comprising: 

initiating a session with a first message from a supplier application to a broker 
application including: 

a schema identifier for the first message, resolvable in a context of a 
system identifier; and 

a polymorphic message comprising a type and a version, wherein the 
polymorphic message including additional data elements 
corresponding to values assigned to the type and version; 

sending a second message from the broker application to a buyer application; 
and 

conducting the session between the buyer application and the supplier 
application. 

65. The protocol of claim 64, wherein the system identifier is explicit in the additional 
message. 

66. The protocol of claim 64, wherein the system identifier for the additional message 
is implicit. 

67. The protocol of claim 64, wherein the buyer application comprises a browser. 

68. The protocol of claim 64, wherein the buyer application comprises a procurement 
application. 

69. The protocol of claim 64, wherein the buyer application comprises a browser and 
a procurement application. 
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70. The protocol of claim 64, wherein the second message forwards at least a portion 
of the first message. 

71. The protocol of claim 64, wherein conducting the session between the buyer 
application and the supplier application includes direct communications between 
the respective applications. 

72. The protocol of claim 64, wherein conducting the session between the buyer 
application and the supplier application includes communications between the 
respective applications through the broker application. 

73. The protocol of claim 64, wherein the polymorphic response is represented in an 
extension of XML. 

74. The protocol of claim 64, wherein the polymorphic response is represented in a 
form compatible with Sox. 

75. The protocol of claim 64, further including the broker application translating a 
supplier's format of the additional data elements to a buyer's format of the 
additional data elements. 

76. The protocol of claim 70, further including the broker application translating a 
supplier's format of the additional data elements to a buyer's format of the 
additional data elements. 

77. The protocol of claim 64, wherein the system identifier comprises a universal 
resource name. 

78. The protocol of claim 64, wherein the additional data elements of the polymorphic 
message are adapted to transmitting a purchase order response. 
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79. The protocol of claim 70, wherein the additional data elements of the polymorphic 
message are adapted to transmitting a purchase order response. 

80. The protocol of claim 64, wherein the additional data elements of the polymorphic 
message are adapted to transmitting an invoice. 

81. The protocol of claim 70, wherein the additional data elements of the polymorphic 
message are adapted to transmitting an invoice. 

82. The protocol of claim 64, wherein the additional data elements of the polymorphic 
message are adapted to transmitting an advance shipping notification. 

83. The protocol of claim 70, wherein the additional data elements of the polymorphic 
message are adapted to transmitting an advance shipping notification. 
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